The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In most communication networks, services, such as security services, inspection and categorization, and other services are applied to packets. Bottlenecks often arise because of resource contention at internal feature modules of communication networks where services, such as security services, are applied. Internal feature modules, such as crypto-engines, are located between the ingress and egress interfaces of a communication network and are invisible to the user. Therefore, if an internal bottleneck occurs at an internal feature module, the user will be unaware of the internal bottleneck. Internal feature modules include components for applying features, which lie in the processing path of a packet in a communication network and may increase latency of packets through the communication network. At times of peak usage, internal bottlenecks can be very severe, causing disruption of end-to-end services and preventing the network from meeting service guarantees specified at egress interfaces.
When services are performed, an internal feature engine, such as a crypto-engine in a router or a switch in the case of security services, performs services on packets on a first-in-first-out (FIFO) basis. Packets of various types, such as real-time data (e.g., voice data) and non-real-time data, are treated equally (e.g., on a FIFO basis) by the internal feature module. No priorities can be assigned to packets today in front of these internal bottlenecks in the packet path and therefore, latency sensitive packets and other data packets (called best-effort packets) have an equal probability of being dropped and an equal treatment in terms of delays experienced in the FIFO queue if a bottleneck occurs at the internal feature module. If drops/delay of bandwidth/latency sensitive data packets occur frequently, there can be undesirable consequences. Some types of real time application traffic are very sensitive to latency, voice over IP being a very good example. If the latency of a voice packet is over 150 ms, the voice quality becomes uncomfortable to the human ear. Drops beyond certain thresholds have a similar effect. It would be desirable to have a method whereby such internal bottlenecks could be effectively handled.
The problems associated with bottlenecks are exacerbated in the context of the application of security services by a crypto-engine where a packet must undergo CPU-intensive operations that include policy checks and encryption/decryption process(es). In security services, such as IPsec, encryption and decryption are applied to data packets. Security services help in the authentication of data and improve confidentiality. During encryption/decryption, methods such as tunneling, which involve packet encapsulation/decapsulation are also employed.
The payload of an original data packet becomes obscured during encryption. Because the payload is obscured, it becomes difficult, if not impossible, to examine the contents of the payload data for attributes that are to be used as criteria for deciding whether to apply certain post-encryption services (e.g., egress services) to the packet. In short, because encryption obscures the payload, it is difficult to determine what post-encryption services should be applied to the packet.
In cases where a crypto-engine is expected to become an internal bottleneck, an option for determining which post-encryption services are to be applied is to use some type of proprietary pre-processing and classification on the packet such as copying the ToS bits from the original IP header. However, ToS bits may not provide enough information for classifying into all different categories. Information from more extensive classification mechanisms such as Access Control Lists that depend on multiple fields within the network/transport protocol headers need to be propagated to post-encryption egress services, which is not possible if such services are applied after the required portions of the packet have been obscured by encryption.
Based on the foregoing, there is a clear need for an efficient means of handling the bottlenecks and obfuscation problems that are associated with the application of services such as encryption at internal feature modules.